Skip to content

test: termlens 0.10.1, and the invariant the PTY suite rests on - #49

Merged
vyncint merged 1 commit into
mainfrom
termlens-0.10.1
Sep 8, 2026
Merged

test: termlens 0.10.1, and the invariant the PTY suite rests on#49
vyncint merged 1 commit into
mainfrom
termlens-0.10.1

Conversation

@vyncint

@vyncint vyncint commented Sep 8, 2026

Copy link
Copy Markdown
Owner

Upgrades the PTY harness from 0.9 → 0.10.1. drag taking four column-first arguments instead of two coordinate pairs was the whole breakage.

74 tests pass. fmt, clippy --workspace --all-targets --all-features, and the full suite are clean locally.

tests/emulation.rs — the invariant everything else rests on

Every screen assertion in this crate reads a grid a VT emulator produced from the binary's bytes — five golden files, two border scans and a styled banner. A sequence that emulator does not implement makes the grid quietly wrong and every one of those assertions a claim about a plausible-looking fiction. The measured answer is one SGR 59: underline colour, which changes no cell. Pinned exactly.

The rest

  • tests/cli.rs drives termlens-cli against this crate's own saved screens — rendered, diffed with its 0/1/2 exit codes, and inspect pointed at the real binary — resolved at the version the lockfile names so tool and library are one release.
  • tests/tui.rs gains coverage using the 0.10 surface, plus a styled golden and a run-metal fixture.
  • The vendored agent skill is refreshed to 0.10.1, and check-skill-version.sh fails when that copy and the dependency disagree on major.minor — it had drifted two releases with nothing to notice.
  • CI writes TERMLENS_ARTIFACT_DIR and renders failures into the job summary via termlens's report action (SHA-pinned).
  • CHANGELOG.md updated under [Unreleased].

The harness moves from 0.9; `drag` takes four column-first arguments now
instead of two coordinate pairs, which was the whole breakage.

`tests/emulation.rs` pins `Screen::unsupported()` exactly. Every screen
assertion in this crate reads a grid a VT emulator produced from the binary's
bytes — five golden files, two border scans and a styled banner — so a
sequence that emulator does not implement makes the grid quietly wrong and
every one of those assertions a claim about a plausible-looking fiction. The
measured answer is one `SGR 59`: underline colour, which changes no cell.

`tests/cli.rs` drives termlens-cli against this crate's own saved screens —
rendered, diffed with its 0/1/2 exit codes, and `inspect` pointed at the real
binary — at the version the lockfile names, so tool and library are one
release.

The vendored agent skill is refreshed to 0.10.1 and check-skill-version.sh
fails when that copy and the dependency disagree on major.minor. CI writes
TERMLENS_ARTIFACT_DIR and renders failures into the job summary.

Signed-off-by: Vyncint Ng <115854244+vyncint@users.noreply.github.com>
@vyncint

vyncint commented Sep 8, 2026

Copy link
Copy Markdown
Owner Author

Updated after adversarial verification. Two independent verifiers re-ran every gate and audited the diff. They found four things worth fixing, three of which were assertions or comments that could not do what they claimed:

  1. A round trip that could not fail. tui.rs read the styled golden back with Screen::parse and asserted frame.diff(&parsed).is_empty(), under a comment saying it proved the file "describes this screen, cell for cell, rather than merely being equal to a string this run produced". But assert_styled_golden on the line above had already asserted the file equals that string — so the diff could only fail if termlens' own round trip were broken, which is a claim about the harness, not about launchbound. Removed; emulation.rs::a_frame_survives_the_snapshot_format_and_json makes that claim properly, against a live screen.

  2. An assertion guaranteed by arithmetic. emulation.rs asserted a 58-character sentence was absent from any single row of a 60-column bordered frame. It could not have fit whatever the renderer did — that is arithmetic dressed as a test. Removed, with the reason recorded; the claim worth making is the one above it (no row is terminal-wrapped, so the breaking was the renderer's doing).

  3. A coverage claim that overstated the loop. The doc said the invariant ran over "both fixtures, all four views and both widths", but run-metal only ran at 80x24. Fixed by adding ("run-metal", (60, 30)) rather than trimming the sentence — the claim is now true and the coverage is real.

  4. A second drift hole this PR opened. cli-version: "0.10.1" is a literal in three workflow files, under a comment claiming it was "the version the lockfile names" — nothing compared them. check-skill-version.sh now checks the workflow pins against the manifest too, and I verified it fails when one goes stale.

Gates re-run after the fixes: fmt, clippy, 74 tests, and the extended check-skill-version.sh all clean.

@vyncint
vyncint merged commit b216902 into main Sep 8, 2026
8 checks passed
vyncint added a commit that referenced this pull request Sep 9, 2026
…t validated (#64)

#58, measured first, and the issue was wrong twice. The geometry half was already done — the suite runs nine tests at 80x24, two at 60x30, and reaches 110x32 by live resize; #49 changed that after I filed the issue. And the TUI emits no colour at all: every style is `Modifier::BOLD` or `BOLD | REVERSED`, `Color::` appears nowhere, and the shipped golden's `styles:` block names only bold and reverse. There was no colour-only cue to lose.

So the tests assert the stronger claim. `no_view_of_the_tui_uses_colour` walks every cell of all four views and asserts fg/bg are the terminal default, structurally via `Cell::style()` — verified by colouring a heading on purpose, which produced "overview: 24 cell(s) carry colour" naming the first eight. `the_metal_banner_keeps_its_emphasis_under_no_color` re-runs the banner assertion under NO_COLOR=1, cell by cell. `no_color_changes_not_one_cell` requires the styled frames byte-identical with and without the variable.

#59: launchbound never reads a register count, does not validate `#[launch_bounds]` against register limits, and does not check `#[launch_contract]` against grid limits. The confusion is earned — `stencil-1d/kernel.toml` opens by narrating register pressure, `lb_max` is a real tuning dimension, and the tool is called launchbound. Sharper than the issue put it: the one `.maxntid` relationship the corpus enforces holds because the kernel author wrote it as a constraint; launchbound attaches no meaning to `lb_max`. README and LIMITATIONS each state the boundary and link to the other, both anchors checked against GitHub's slug rules.

Closes #58
Closes #59

Signed-off-by: Vyncint Ng <115854244+vyncint@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant